Different notations are used to describe systems from particular perspectives. To describe software systems, modeling languages such as UML, programming languages themselves such as C++, or even machine code are a few examples of notations used frequently.
Notations at a similar abstraction level often carry a great portion of overlapping information. For example, source code can also be represented as a UML model. Similarly, representing the same system, a general platform-independent model (PIM) and a model which specifically targets a particular platform would also have a large overlap.
Even for overlapping notations, each of them captures unique aspects of the system. Therefore using both is desirable. This results in a burden, to maintain the consistency and integrity of the overlapping descriptions. Such maintenance can be automated, if a formal bi-directional transformation exists between the overlapping parts of the two notations. An automatic transformation can “transfer” changes from a description in one notation into the other. A formal bi-directional transformation is called a “mapping” in the following description.
In OMG MDA the term “mark” is used to select a transformation to be applied. However, no particular mechanism to specify the transformations themselves is suggested. There are also general-purpose techniques such as XSLT to describe transformations between XML documents. These techniques are targeted to programmers not end users. In addition most methods don't address creating mappings; they are only concerned with one-directional transformations.
Mappings which are predefined such that users cannot change them are called “fixed” in the following. Fixed mappings are commonplace. For example, the JSR-026 standard specifies a fixed mapping between UML models and java code. A fixed mapping has the benefit that it is comparatively easily supported by software tools. Fixed mappings however have severe non-obvious weaknesses:                I. Their arbitrary mapping choices are either too simplistic or too complex.        II. They tend to not use existing information to derive content.        III. They tend to disconnect the mapped content.        IV. They result in a fixed perspective.These weaknesses are best explained using examples.        
In UML two classes can be related via an AssociationEnd. The quality of this relationship is captured with properties such as Kind (Aggregation, Composition or Simple), its Ordering (Unordered, Ordered) and Multiplicity. There are many different ways how two classes related by an AssociationEnd can be mapped to code. A fixed mapping will have to arbitrarily select a particular bidirectional transformation.
With respect to I and II above, the JSR-026 introduces additional tags such as JavaCollection and JavaDimension. These tags are used instead of the already defined AssociationEnd's properties. If the JavaCollection's tagged value is set it defines the Type used to implement the AssociationEnd in code. JavaDimension is used to augment the type found in the AssociationEnd's TypeExpression with Java array brackets. Both replace the existing properties TypeExpression, Multiplicity and more.
A better mapping uses model information when deriving code. However this burdens every user with the complexity to understand the transformation even if they don't benefit from the additional complexity. This is probably the reason why most fixed mappings stop using relevant modeled information in favor of relying on introducing tagged values at some point.
This conflict is emphasized in complex mapping situations that don't naturally have a bi-directional transformation which users would universally accept as natural. For example consider possible mapping of an AssociationEnd to the C++ code “mylist<Foo*, N, HeapAllocator>”.
With respect to III above, the JSR mapping uses a default transformation if neither JavaDimension nor JavaCollection are set. This default transformation generates the code based on the AssociationEnd's Supplier. The code will change as the Supplier is changed. However once JavaCollection is set the AssociationEnd's Supplier is not considered. The code becomes disconnected from the native UML properties of the AssociationEnd. This is highly undesirable and has a side-effect of not deriving the code from existing UML properties. This issue is impossible to resolve with a fixed mapping when there is no universally agreed upon mapping without becoming highly complex.
With respect to IV above, using a fixed mapping results in a fixed perspective. For example consider the model when mapping the C++ code “mylist<Foo*, N, HeapAllocator>Foos;. A fixed mapping will result in a model capturing mylist, Foo, N, HeapAllocator somewhere with the AssociationEnd. Therefore the AssociationEnd will be unable to capture the code in UML spirit using the UML properties (Multiplicity, Ordering, Supplier, etc.) as much as possible.